home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1131 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: "Kevin O'Donovan" <abaddon@nasoftwr.demon.co.uk>
  2. Subject: Re: Make It Simple
  3. Date: Fri, 29 Jul 1994 14:32:28 +0100 (BST)
  4. In-Reply-To: <memo.809267@cix.compulink.co.uk> from "Ofir Gal" at Jul 29, 94 10:04:00 am
  5. Precedence: bulk
  6.  
  7. Ofir Gal said:
  8.   > I don't think we need application specific stuff.
  9. My main concern would be that it could start taking a long time to parse.
  10. Under X, which seems to be were most people are getting there ideas from,
  11. the file is not read every time an application loads, instead it is read
  12. once (or upon request) into an X resource database. I'm not sure how
  13. applications interact with the database, but however they do it it has to
  14. be faster than reading and parsing a file every time you run. If I fire up
  15. an editor to make a quick change I want it available right away.
  16.  
  17.   > I think most users would prefer click-to-type, if you have to move the
  18.   > mouse you may as well click it.
  19. I think it would be about equal. In my experience preferences are split
  20. without half the people not having a clue whats going on, and the remaining
  21. half equally split to what they prefer. Until you've worked in a point to
  22. type environment you can't really understand its benefits.
  23.  
  24.  
  25.   > I don't think this should be in the
  26.   > standard or in the app-defs file because very few programs will support
  27.   > it.
  28. I'd agree, but for a different reason. If its available it should be a global
  29. option, otherwise its going to be very confusing. The only way to make it
  30. a global option is to change the AES. This is why I don't plan to support it.
  31. As far as my library's concerned whatever happens outside its window work area
  32. is the domain of the window service provider.
  33.  
  34.   > KEYS
  35.   > *.*.*.*.*.*.
  36.   > etc...
  37.   > 
  38. Not sure I like this, but that's quite possibly because I'm biased towards
  39. the .Xdefaults style. Given I can't come up with a concrete objection I guess
  40. you should just ignore me ;-)
  41.  
  42.   > Couldn't we just use pseudo code so that everyone understands it. I don't
  43.   > know C well enough to follow your code.
  44.   >
  45. If its provided in object code, and assuming that the interfaces match OK,
  46. you wouldn't have to read his code, you'd just call it. C or assembler
  47. would be the ideal languages to write such multi-language code in.
  48.  
  49.   > I hope you are wrong. I don't think any app should write to the file, only
  50.   > read.
  51.   >
  52. Agreed. Whatever we eventually decide the domain of the defaults file to be,
  53. it should not be application writeable.
  54.  
  55.   > Why not save them the same way they are displayed in the menu? ^Q, etc.
  56.   > 
  57. No real reason, as long as we choose something consistent. It could be worth
  58. stealing a few ideas from .Xdefaults, as it does allow the user to specify
  59. all sorts of events as well as key ones.
  60.  
  61. Kev
  62. -- 
  63. Kevin O'Donovan
  64. abaddon@nasoftwr.demon.co.uk
  65. kebab@cix.compulink.co.uk
  66.  
  67. Chaotic Amorals have more fun
  68.  
  69.